Dark Wolf Hack Our Drone

You have received a special delivery from your customer. - You choose to [[receive the package ->Open Package]] - You choose to [[refuse the package ->Refuse Package]]

You open the package and find a case holding a Unmanned Aerial Vehicle (UAV) and Ground Control System (GCS) Do you - [[Examine the UAV ->Examine UAV]] - [[Examine the GCS ->Examine GCS]]

You don't have time for this. You refuse to sign for the delivery and tell the shipper to [[return the package. ->FAFO]]

Your customer is very unhappy. In a few days, you are notified that your security clearances have been suspended. You send notice that you are very sorry and will be happy to [[receive the package ->Open Package]]

You see a quadcopter drone. It has four arms with four props. There is cowl covering the airframe. - [[ Return to the case ->Open Package]] - [[ Disassemble the UAV ->UAV Disassembly]]

You see a handset very much like a game controller with joysticks and buttons to the left and the right and a screen in the middle. There is a slight protuberance on the back of the device. What do you do next? [[Disassemble the GCS ->GCS Disassembly]] [[Examine the UAV ->Examine UAV]]

Try as you might, you cannot find all the screws that held the UAV together. But with careful review of your notes and camera snapshots, you sucessfully reassemble the UAV. What comes next? - [[Re-examine the UAV ->Examine UAV]] - [[Examine the GCS ->Examine GCS]]

You see a set of four test pins on the PCBA which appear to be a UART serial port. The GND, RX, TX, and VCC labels on the board make it pretty obvious. But unless you power on the UAV, you will not be able to access the serial console. - Power on the UAV and [[access the serial console ->UAV Serial Console]] - Return to [[examine the other UAV components ->UAV Disassembly]]

The UAV Flight Control Unit (FCU) is a SIngle Board Computer (SBC) with many ports for connecting to the radio, cameras, and payloads. Also there are comm ports such as serial, CAN, and ethernet. Continue the examination ... - [[Examine the UAV FCU Ethernet ->UAV Ethernet]] - [[Examine the UAV Serial Ports ->Examine UAV Serial Ports]] Or return to the UAV to ... - [[examine the other components ->UAV Disassembly]]

You restart the flight computer. As the bootloader serial console session begins, you repeatedly hit the enter bar until the bootloader pauses. It does not pause. It just scrolls right down to a serial console root login prompt. The serial boot console is configured for output only; keyboard input is disabled. There is no cheese down this path. Where to now? - [[Examine UAV]] - [[Examine Radio]] - [[Examine GCS]] Or maybe ... just maybe .... - [[Review the boot console output->UAV Bootloader]]

Try as you might, you cannot find all the screws that held the GCS together. But with careful review of your notes and camera snapshots, you sucessfully reassemble the GCS. What comes next? [[Examine the UAV ->Examine UAV]] [[Rexamine the GCS ->Examine GCS]]

You take the take the back cover off of the GCS. You see several components Which do you choose to examine closer? - [[Examine the Embedded Android Phone ->Examine GCS Android]] - [[Examine the Single Board Computer ->Examine GCS SBC]] - [[Examine the Radio ->Examine Radio]] - [[Reassemble the GCS ->GCS Reassembly]]

You extract the Android phone from the rest of the Ground Control System. It is a standard off-the-shelf phone. It connects to the rest of the GCS via a small USB-C cable. You power up the phone and it prompts for a PIN password. - You try to [[brute force the PIN ->GCS Android PIN]] - Or you can [[check out the USB-C port ->GCS Android USB-C]]

The integrated radio provides several access methods including a //serial console// and //ethernet lan// interface. After applying power to the board in accordance with the documentation, how do you proceed? - [[Examine the serial console ->Examine RF Serial]] - [[Examine the ethernet interface ->Examine RF Ethernet]] - [[Return to the Disassembled GCS->UAV Disassembly]]

You connect a USB-TTL adapter to the radio and open up a //minicom// session on your Linux laptop. As the radio powers up, you see a //U-Boot //bootloader session followed by a Linux kernel boot up. An //OpenWRT// banner is displayed and the serial consoles flashes a login prompt. - [[Guess the password ->Guess RF Password]] - [[Attempt Bootloader Attack ->Attack RF Bootloader]]

You power up the radio and attach one end of an ethernet cable your laptop and the other end to the 4 pin ethernet port. You find that the radio provides a DHCP address to your laptop. You run an nmap scan and find a ssh port and a web port open. - [[Connect to SSH service with a ssh client->RF SSH]] - [[Connect to web service with a ssh client->RF HTTP]]

You take the cowl off the UAV. You see several different components. Which do you choose to examine closer? - [[Examine the Flight Control Unit ->Examine UAV FCU]] - [[Examine the UAV Serial Ports ->Examine UAV Serial Ports]] - [[Examine the UAV Radio ->Examine Radio]] - [[Reassemble the UAV ->UAV Reassembly]]

You remember seeing a //default password// in the vendor documentation for this radio. As it turns out, the default password has never changed. You are now logged in as root on the radio. - [[Continue in the Radio's console->RF CLI]]

You restart the radio. As the bootloader serial console session begins, you repeatedly hit the enter bar until the bootloader pauses. You run commands to find the bootup variable which controls the command line arguments being passed to the Linux kernel boot command. You modify this to use //'/bin/sh'// as the init script instead of the standard init command. After this modification, you let the bootup sequence proceed. As the Linux kernel finishes booting, you are automatically logged into the radio's operating system as the root user. - [[Continue in the RF console->RF CLI]]

As the root user, you have full access to the software on this radio. How do you use your powers? - [[Search for SSH keys->RF SSH Keys]] - [[Search for the radio configuration->RF Config]]

You do not find any SSH private keys that could be use to login to other radios or vendor systems, but you do find a large listing of authorized-keys that include the emails of the vendor's developers or support staff engineers that were used to login to this radio. What to do? - [[Add this list of vendor emails to your security report->Edit Report]] - [[Sell this list of vendor emails on the black market->Sell on DarkNet]]

With a few key word searches, you are able to locate the radio's configuration files. Stored in these files are items such as frequency, modulation, and encryption keys of for this radio configuration. What should you do with this information? - [[Add this information to the security assement report->Edit Report]] - [[Sell this information on the Darknet->Sell on DarkNet]]

Nice find! Along with all the other security misconfigurations and leaked information you have collected so far, this is going to be a juicy report. Perhaps there is more to find! - [[Examine UAV]] - [[Examine GCS]] - [[Examine Radio]]

You start up your TOR browser and login to the Silk Road onion site on the darknet. There you offer up your secrets to the highest bidder. Unfortunately for you, the only interested buyer is a US Federal officer hanging out on the astroturf site collecting names and issuing warrants for skids who think Silk Road is still a thing. Sorry, but you are looking at 5-20 in a federal prison. - [[Repent and begin again->Package Delivery]]

After fiddling a bit with some obscure SSH options (how old is this software?!), you finally connect to the ssh service. It prompts you for a password. - [[Attempt to guess the password ->Guess RF Password]] - [[Abandon hope and try the web server ->RF HTTP]] Or fall back and try something else - [[Examine UAV]] - [[Examine Radio]] - [[Examine GCS]]

As you open your web browser and navigate to the radio's web page, you are prompted for a user name and password. You recall seeing default user names and password in the radio documentation you downloaded earlier. You try them. Of course they work. As you browse the radio's web pages, you see they are for setting the radio's configuration. But you also notice a panel that allows you to enter arbitrary commands for debug and troubleshooting. - [[Use the web pages embedded terminal->RF CLI]] This has to be a trap. Back away slowly and ... - [[Examine Radio]] - [[Examine UAV]] - [[Examine GCS]]

You connect an ethernet cable from your computer to an ethernet breakout board. You connect the four data wires from the breakout board to the the 4-pin ethernet port on the SBC. When you apply power to the SBC, the ethernet becomes active and assigns an IP address to your laptop. You run the command line tool //nmap// to look for open network service ports. You find a ssh service on port 22. You also scan a list of UDP ports commonly associated with MAVLink - a common UAS telemetry protocol. You find several open MAVlink ports. - [[Connect to SSH service on TCP/22 ->UAV Ethernet SSH]] - [[Connect to MAVLink service on UDP/14550->UAV Ethernet MAVLink]]

You examine the Single Board Computer (SBC_) integrated into the Ground Control System. It is a custom board but you recognize some of the parts on the board. There is a Qualcomm SOC, a Macronix flash chip, a Realtek ethernet controller chip, and a USB-C port. The board is powered by two integrated lithium batteries. There is a power button. - [[Try to dump the flash memory ->Examine GCS SBC Flash]] - [[Connect to the USB-C port ->Examine GCS USB-C]]

Fortunately for you, the flash memory chip is a SOIC chip with exposed pins. You have a matching SOIC clip and connect the clip to the chip. Wires run from the clip to your Bus Pirate FT232 programmer board. You connect the Bus Pirate to your laptop and run the '//flashrom//' command line tool. It successfully connects to the Macronix flash memory chip and dumps the memory to file. You run the //binwalk// command line tool on the memory dump file. It extracts a //squashfs// file system. You are able to mount the unencrypted file system on your Linux comptuer using standard file system mount tools. You search the file system for interesting files: passwords, ssh keys, encryption keys, network service software, communication protocols. There is a lot here. But one thing that catches your eye is a software package that includes a bunch of APIs for contacting a cloud based service. As you dig deeper, you determine that this is fleet management software. No need to worry. This is fine. Let's find something else. - [[Examine GCS]] - [[Examine UAV]] - [[Examine Radio]] Or dig deeper into the fleet management tools. - [[Investigate Software ->Examine GCS FleetMgmt SW]]

You power up the GCS SBC and connect a USB-C cable between the SBC and your laptop. An ethernet port is activated and you receive an IP address. You bring up wireshark and sniff the network traffic. In the network traffic, you see DNS requests for a cloud based domain name and repeated API call to the same domain. The packet data appears to be encrypted, but the API is using *http basic auth*. On a hunch, you isolate the packet, dump it from Wireshark, and resend it to the cloud-based API server. It receives a HTTP 200 success response and an encrypted data response. You reconfigure your laptop to act as a forwarding NAT'd router and a steady stream of data passes back and forth between the GCS SBC and the cloud-based API. How to proceed? You need the encryption key to decrypt the packet data. Go back and [[look for a way to get that key ->Examine GCS SBC]] You could skip the packet data and [[check out the API web server ->GCS FleetMgmt Server]] This is too hard. Let's try something easier. [[Examine UAV]] [[Examine Radio]] [[Examine GCS]]

Time to bring out //Ghidra// and perform some reverse engineering analysis. Ghidra performs the disassembly and decompilation routines. Lucky for you, this software was compiled with debugging information enabled and all the variables and function names appear as they did in the original source code. As you read through the code, you realize that status information is being sent to the cloud while commands and configuration are being received from the cloud. Incoming commands are authenticated by a simple HTTP basic auth command. The same password is being used to send status into the cloud. The packet data is being encrypted .... *by the same password!!!* So where is the password? It's not in the code. It's not in the ///etc/shadow// file. You find a function that is reading the password out of a hardcoded memory location. That's convenient since you have dumped all the memory from the SBC. You return to the memory dump and carve out the password. How can you be *really* sure that this is the right password? You check through the code for a simple looking API call and run it using http basic auth, the username and password you have located, encrypted packet data (based on the function in the code), and a //curl// command. Success! Nice job. You have a found a vulnerablity that could be used to sniff data from the GCS when it is connected to the network or could be used to reconfigure its security settings. What do you want to do this? - [[Add it to the security assessment report ->Edit Report]] - [[Investigate the cloud server ->GCS FleetMgmt Server]] Or decide that this is a dead end and go look at something else? - [[Examine UAV]] - [[Examine Radio]] - [[Examine GCS]]

You do some basic recon around the DNS name of the Fleet Management API endpoint. You search for subdomains related to the domain name. You create an free-trial account with the service and read through the documentation. After collecting as much data as you can find, you move to active recon measures. You spin up //nmap// and check out the ports of the Fleet Management server. Not much there - just web services. You attempt to access the root directory of the API URLs and are connected to a UAS Management web site. It asks for credentials. You use the same credentials you have been using with the API calls. You are logged in. This account is responsible for managing hundreds of UAS. You have the ability to reconfigure them, create new flight plans and send them to the UAS, download all the log files, change all the security settings, or to upload new software. Poor credential management and password reuse has just led you to a major breach. Awesome! The temptation is real. What do you want to do with this? - The retirment plan for cyber criminals sucks. You decide to [[add this to the security assessement report ->Edit Report]] - But you are not the average cyber criminal. You decide to [[sell this on the darknet ->Sell on DarkNet]]

The Android phone PIN Is ridiculously simple and you find the PIN //123456// soon enough and have access to the Android home screen. How do you want to proceed? - [[Check out the phone's apps and files via the standard UI ->GCS Android UI]] - [[Enable the Android ADB debugger in the Settings ->GCS Android ADB]]

You connect a USB-C cable from your laptop to the Android phone and power it on. You can see an ethernet port activate on your laptop, but there is no IP address assigned to it. You start the tcpdump command line tool and sniff the network traffic. You see that the phone is sending ARP packets from 192.168.0.10 looking for a MAC address for 192.168.0.1. You set the USB-C ethernet to the static IP address 192.168.0.1 and start seeing network traffic from the phone. Much of the traffic appears to be standard Android traffic. But you see some traffic to and from a cloud based API. The traffic is all encrypted, so you don't see much besides the endpoints. Some passive reconnaissance shows that the endpoint IP is flagged in a malware database list of //'indicators of compromise//' as stalkerware. That's not good. - [[Review the open source data on this stalkerware->GCS Android Stalkerware]] - [[Go back and get more data from the phone ->Examine GCS Android]]

You scroll through the list of installed apps. Seems pretty normal. You see some ground control mission software apps for controlling the UAV. Pretty bare. Looks like most of the default apps have been stripped out too. You open the file browser and look for interesting files. Still not much to see. There is a logs directory but no logs. No docs, no pictures, no videos, no downloads, no leftover apks. Clean phone. Time to move on. - [[Examine UAV]] - [[Examine Radio]] - [[Examine GCS]] Or you can reconsider. Time to try harder on the phone. - [[Examine GCS Android]]

You open the Settings app and find the //developer mode// is already enabled. You reset the default USB behavior and connect a USB-C cable from your laptop to the phone. A permission dialog pops-up asking for approval for your laptop to connect in debug mode. You approve the dialog. You connect to the phone from your laptop with the //adb// command line tool. You list the installed apps. Things seem pretty normal, even sparse. There are a couple of UAV related apps you recognize. Some standard Google and vendor apps. But then there is *this* app: *org.xFGh1* What the heck is that? You dump the APK and do some reverse engineering on it. This thing has a lot of permissions enabled. Messages, Contacts, Location, Call Logs. You notice that it installs under the name //"Connection Tools"// While the app has been compiled with obuscation tools, you run command line tool strings on the native shared libraries included with the apk and pull out some interesting ones and search for them on a malware database of //'indicators of compromise'//. Several of them are flagged as belonging to a known //stalkware// app. - [[Review the open source data on this stalkerware->GCS Android Stalkerware]] - [[Go back and get more data from the phone ->Examine GCS Android]]

Using the matches from the *indicators of compromise* database, you expand your open source research on this stalkerware app. It's been seen in the wild for sometime. Also, it turns out that while obfuscated, the code quality is not that great. Someone discovered a *remote code execution* (RCE) vulnerability in the code and can use that to get system level access over the network on any phone that has this stalkerware installed. Woah! If this is a widespread supply chain problem with this UAS vendor, then all their GCS Android phones might have this malware and backdoor installed. It's even possible that the upstream phone manufacturer is affected. This could have wide impact. [[Add the finding to your security assessment report ->Edit Report]] [[Sell this information on the Darknet->Sell on DarkNet]]

You connect to the UAV FCU with a ssh client. You are prompted for a login password which you do not have. You will need to try something else - [[Try the MAVLink service ->UAV Ethernet MAVLink]] Or something completely different - [[Examine UAV]] - [[Examine Radio]] - [[Examine GCS]]

You start up the MAVProxy tool and connect to the UAV FCU on the UDP/14550 port. Success! You are receiving MAVLink packets with data about the configuration and status of the UAV FCU. You type the *ftp list* command into the MAVProxy console. It connects and responds with a directory listing. You try another command *ftp list ..* and you get a directory listing of the ftp root parent's directory. *Excellent!* you think as you quickly create a ssh key pair on your laptop. You then download the "*/home/pilot/.ssh/authorized-keys*" file, add your public key to the file, and upload back into the same directory. - You try to [[login to the SSH service ->UAV FCU SSHPrivKey]] with your private key. Or maybe not. Is this really fair? - [[Examine UAV]] - [[Examine Radio]] - [[Examine GCS]]

You connect to the UAV FCU SSH service with a ssh client and the private key you just created. It works! You are now logged into a Linux operating system running on the UAV FCU. You snoop around checking a few things. You can pull log files, You can access the flight software configuration parameters. You can see the video feed storage, although no videos are present. You recall that there were some existing keys in the *authorized-keys* file you downloaded. You wonder who might have logged into the UAV previous to delivery. You check the// /home/pilot/.bash-history// file. Bingo! There are a TON of commands in the history file. Many hundreds. Included among them are complete SSH Private Keys that were uploaded to the UAV by use of an *echo* command. Nobody would do that? Right? But you then see these keys are being used to access a git repository to download flight software modules. This isn't gitlab.com or github.com; this is a vendor's private git repository. - Should you stop now and [[add this to the security assessment report ->Edit Report]] - Or should you [[investigate further ->UAV GitRepo]]

On your laptop, you test the SSH Private Key and one of the git commands you found in the *bash history* of the FCU pilot account. It works. You test some others. They work. You have full read access to the vendors UAV software repos. Just *read* access, you wonder. What about *write* access? You look through the commits and other user data on one of the repos. You are pretty sure you can use an cloud based IP and fake some user data to be able to commit a minor code change to one of the repos that would not be an obvious outsider attack. But should you? - Nope. This is far enough. [[Report what you found ->Edit Report]] - Yup. This is too important to not determine the scope of the vulnerability and [[run the code injection ->UAV GitRepo Hack]]

You create the code change, add it, commit it, and push it. It works. Your code is accepted. This is crazy dangerous. You drink some water. You go outside and touch the grass. You come back inside, resolved. - You will [[include this in your report ->Edit Report]] and let the responsible parties deal with it. - You know what can be done with this. You could install a rootkit or other backdoor on every drone the vendor provisions. You decide look for a [[black hat zero day broker to buy this explot. ->Sell on DarkNet]]

The output from the bootloader shows it pausing for four seconds while it checks to see if there is an TFTP bootloader service running on the ip address 192.168.1.1. Well, you have a TFTP bootloader service running on your laptop. You also know the how to build a bootable image for this single board computer. It won't be the exact same build as installed now, but that is okay. It just needs to boot up and start up a ssh service. So you build a custom image for this type of single board computer. You place the boot image into your TFTP service root directory. You connect to the ethernet port on the UAV FCU and assign your ethernet port the ip address 192.168.1.1. You also start a network sniffer. You power on the UAV FCU. It starts up and you see your etherent port connection LEDs light up. A moment later, your network sniffing tool sees the boot image being transferred to the the UAV. You check your serial console and see that the bootloader has succesfully booted your image. You are lucky today! As the boot sequence concludes, a login prompt appears. - [[You login with your known password. -> UAV CLI]]

So you are logged into the UAV FCU SBC. But logged into your operating system and not into the operating system the drone flys on. So you run some commands looking for the partitions on the UAV FCU SBC flash drive. You find them and dump the flash memory to files that you download and examine on your laptop. You find an encrypted root file system in the memory dumps. Darn. But the encryption key is probably in memory somewhere. After a few minutes, you find it in another partition dumpfile. You use the filesystem encryption key to decrypt the root file system and mount it on your Linux laptop. So far so good. You snoop around checking a few things. You can pull log files, You can access the flight software configuration parameters. You can see the video feed storage, although no videos are present. You note that there are some existing keys in the *authorized-keys* file in the */home/pilot/.ssh* directory. You wonder who might have logged into the UAV previous to delivery. You check the /home/pilot/.bash-history file. Bingo! There are a TON of commands in the history file. Many hundreds. Included among them are complete SSH Private Keys that were uploaded to the UAV by use of an *echo* command. Nobody would do that? Right? But you then see these keys are being used to access a git repository to download flight software modules. This isn't gitlab.com or github.com; this is a vendor's private git repository. - Should you stop now and [[add this to the security assessment report ->Edit Report]] - Or should you [[investigate further ->UAV GitRepo]]

↶

↷

You have received a special delivery from your customer.
- You choose to

receive the package

- You choose to

refuse the package